WASI 0.2 GA: Truly Composable WebAssembly

javi
Bloques modulares metálicos ensamblándose representando componentes componibles

WASI 0.2 Preview 2 reached GA in January 2024, and with it, the WebAssembly Component Model. This is decisive moment: server-side WebAssembly moves from experiment to platform capable of executing composable polyglot code. This article covers what practically changes, when to choose server-side Wasm, and what cases are viable today.

What the Component Model Is

Before 0.2, server-side WebAssembly was WASI Preview 1: Unix-like syscalls. Each module was an island — integrations were manual.

Preview 2 Component Model adds:

  • WIT (WebAssembly Interface Types): cross-language interface definitions.
  • Components: composition unit (like Rust crates or npm packages, but multi-language).
  • Dependency injection: components consume interfaces, pluggable.
  • Type safety across language boundaries.

Result: you can write one component in Rust, another in Go, another in JavaScript, and compose them without manual glue code.

WIT Example

package example:greeter@1.0.0;

interface greeter {
    greet: func(name: string) -> string;
}

world host {
    export greeter;
}

Any language compiling to Wasm component can implement or consume this.

Viable Real Cases

Edge Serverless

Fastly Compute, Cloudflare Workers (with Wasm), Fermyon use server-side Wasm for:

  • Low cold-start (<1ms).
  • Strict sandboxing.
  • Multi-runtime portability.
  • Massive scaling.

Plugins for Host Apps

A host app can load Wasm components as plugins:

Portable plugins between runtimes without recompiling.

Embedded and IoT

Wasm runs on devices with kilobytes of memory:

  • wasm-micro-runtime (WAMR): for IoT.
  • Customisable firmware without reflashing.
  • Sandbox for untrusted code.

Main Runtimes

Wasmtime is safest default. Others have specific focuses.

Compatible Languages

Variable maturity:

  • Rust: first-class citizen (componentize-rs, cargo-component).
  • Go: TinyGo supports (limitations vs full Go).
  • C/C++: via wasi-sdk, mature.
  • JavaScript: via Javy (for edge), Componentize-JS.
  • Python: experimental via componentize-py.
  • .NET: emerging support.
  • Java: via WASI-libc, less common.

Rust is lowest-friction path. Others closing gap.

A Rust Component

// cargo-component new hello
cargo component build --release

Configure WIT, implement interface, compile to .wasm component. Usable from any Wasm host supporting CM.

WASI 0.2 Interfaces

Provides standard interfaces:

  • wasi:filesystem: FS access.
  • wasi:sockets: TCP/UDP.
  • wasi:http: HTTP client/server.
  • wasi:clocks: time.
  • wasi:random: RNG.
  • wasi:cli: stdin/stdout/env.

Code can target these interfaces; runtime implements per context.

Vs Docker / Containers

Does Wasm replace containers? Depends:

Aspect Wasm component Container
Cold start <1ms 100ms-1s
Size KB-MB MB-GB
Isolation Very strong Good
Ecosystem Emerging Massive
Multi-language Yes (via CM) Yes
OS access Limited (safer) Full

For edge functions, serverless, plugins, Wasm wins. For traditional apps or legacy, containers remain default.

Kubernetes and Wasm

Integrations:

  • krustlet: kubelet for Wasm (legacy).
  • runwasi: containerd runtime for Wasm.
  • kwasm: operator to enable Wasm on K8s nodes.

Running Wasm directly on K8s without containerising is possible today.

Limitations

  • Ecosystem still emerging: many libraries missing.
  • Debugging: harder than native or container.
  • Async story: improving but unfinished.
  • Performance: close to native but not equal.
  • GC languages: less efficient when targeting Wasm.

Cases to Use Wasm Today

  • Edge functions with critical cold start.
  • Secure plugins for host apps.
  • Untrusted-code sandboxing.
  • Cross-platform portability (code runs the same on Mac, Linux, Windows, ARM, x86).

Cases to Wait

  • Traditional web apps: no clear advantage over containers.
  • Databases: Wasm runtime immature for heavy stateful.
  • Heavy computation: native or GPU remain better.

Future

Near-term roadmap:

  • More languages with component model support.
  • WASI 0.3: async, threads.
  • More runtime support: Cloudflare Workers full Component Model.
  • Unified tooling: ecosystem consolidation.

Clear direction but several years to container-comparable maturity.

Conclusion

WASI 0.2 GA is a significant milestone. Component Model resolves cross-language portability that blocked adoption. For edge functions, secure plugins, and extreme portability, server-side Wasm is viable today. For traditional apps, doesn’t replace containers — complements them. Teams building edge functions or platforms with plugins should evaluate Wasm. For the rest, it’s technology to follow but not urgent to adopt. Wasm convergence with Kubernetes and containerd is another maturity signal — ecosystem is connecting, not fragmenting.

Follow us on jacar.es for more on WebAssembly, edge computing, and modern architectures.

Entradas relacionadas